<?xml version="1.0" encoding="iso-8859-1" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="Content-Type" content=
    "application/xhtml+xml; charset=iso-8859-1" />
    <title>
      About Firmware
    </title>
    <link rel="stylesheet" type="text/css" href="../stylesheets/lfs.css" />
    <meta name="generator" content="DocBook XSL Stylesheets V1.79.1" />
    <link rel="stylesheet" href="../stylesheets/lfs-print.css" type=
    "text/css" media="print" />
  </head>
  <body class="blfs" id="blfs-9.1">
    <div class="navheader">
      <h4>
        Beyond Linux<sup>�</sup> From Scratch <span class="phrase">(System
        V</span> Edition) - Version 9.1
      </h4>
      <h3>
        Chapter&nbsp;3.&nbsp;After LFS Configuration Issues
      </h3>
      <ul>
        <li class="prev">
          <a accesskey="p" href="console-fonts.html" title=
          "About Console Fonts">Prev</a>
          <p>
            About Console Fonts
          </p>
        </li>
        <li class="next">
          <a accesskey="n" href="devices.html" title="About Devices">Next</a>
          <p>
            About Devices
          </p>
        </li>
        <li class="up">
          <a accesskey="u" href="config.html" title=
          "Chapter&nbsp;3.&nbsp;After LFS Configuration Issues">Up</a>
        </li>
        <li class="home">
          <a accesskey="h" href="../index.html" title=
          "Beyond Linux� From Scratch     (System V Edition) - Version 9.1">Home</a>
        </li>
      </ul>
    </div>
    <div class="sect1" lang="en" xml:lang="en">
      <h1 class="sect1">
        <a id="postlfs-firmware" name="postlfs-firmware"></a>About Firmware
      </h1>
      <p>
        On some recent PCs it can be necessary, or desirable, to load
        firmware to make them work at their best. There is a directory,
        <code class="filename">/lib/firmware</code>, where the kernel or
        kernel drivers look for firmware images.
      </p>
      <p>
        Preparing firmware for multiple different machines, as a distro would
        do, is outside the scope of this book.
      </p>
      <p>
        Currently, most firmware can be found at a <strong class=
        "userinput"><code>git</code></strong> repository: <a class="ulink"
        href=
        "http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/">
        http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/</a>.
        For convenience, the LFS Project has created a mirror, updated daily,
        where these firmware files can be accessed via <strong class=
        "userinput"><code>wget</code></strong> or a web browser at <a class=
        "ulink" href=
        "http://anduin.linuxfromscratch.org/BLFS/linux-firmware/">http://anduin.linuxfromscratch.org/BLFS/linux-firmware/</a>.
      </p>
      <p>
        To get the firmware, either point a browser to one of the above
        repositories and then download the item(s) which you need, or install
        <strong class="userinput"><code>git</code></strong> and clone that
        repository.
      </p>
      <p>
        For some other firmware, particularly for Intel microcode and certain
        wifi devices, the needed firmware is not available in the above
        repository. Some of this will be addressed below, but a search of the
        Internet for needed firmware is sometimes necessary.
      </p>
      <p>
        Firmware files are conventionally referred to as blobs because you
        cannot determine what they will do. Note that firmware is distributed
        under various different licenses which do not permit disassembly or
        reverse-engineering.
      </p>
      <p>
        Firmware for PCs falls into four categories:
      </p>
      <div class="itemizedlist">
        <ul class="compact">
          <li class="listitem">
            <p>
              Updates to the CPU to work around errata, usually referred to
              as microcode.
            </p>
          </li>
          <li class="listitem">
            <p>
              Firmware for video controllers. On x86 machines this seems to
              mostly apply to ATI devices (Radeon and AMDGPU chips) and
              Nvidia Maxwell and Pascal cards which all require firmware to
              be able to use KMS (kernel modesetting - the preferred option)
              as well as for Xorg. For earlier radeon chips (before the
              R600), the firmware is still in the kernel.
            </p>
          </li>
          <li class="listitem">
            <p>
              Firmware updates for wired network ports. Mostly they work even
              without the updates, but probably they will work better with
              the updated firmware. For some modern laptops, firmware for
              both wired ethernet (e.g. rtl_nic) and also for bluetooth
              devices (e.g. qca) is <span class=
              "emphasis"><em>required</em></span> before the wired network
              can be used.
            </p>
          </li>
          <li class="listitem">
            <p>
              Firmware for other devices, such as wifi. These devices are not
              required for the PC to boot, but need the firmware before these
              devices can be used.
            </p>
          </li>
        </ul>
      </div>
      <div class="admon note">
        <img alt="[Note]" src="../images/note.png" />
        <h3>
          Note
        </h3>
        <p>
          Although not needed to load a firmware blob, the following tools
          may be useful for determining, obtaining, or preparing the needed
          firmware in order to load it into the system: <a class="xref" href=
          "../general/cpio.html" title="cpio-2.13">cpio-2.13</a>, <a class=
          "xref" href="../general/git.html" title=
          "Git-2.25.0">git-2.25.0</a>, <a class="xref" href=
          "../general/pciutils.html" title=
          "pciutils-3.6.4">pciutils-3.6.4</a>, and <a class="xref" href=
          "../basicnet/wget.html" title="Wget-1.20.3">Wget-1.20.3</a>
        </p>
      </div>
      <p class="usernotes">
        User Notes: <a class="ulink" href=
        "http://wiki.linuxfromscratch.org/blfs/wiki/aboutfirmware">http://wiki.linuxfromscratch.org/blfs/wiki/aboutfirmware</a>
      </p>
      <div class="sect2" lang="en" xml:lang="en">
        <h2 class="sect2">
          <a id="cpu-microcode" name="cpu-microcode"></a>Microcode updates
          for CPUs
        </h2>
        <p>
          In general, microcode can be loaded by the BIOS or UEFI, and it
          might be updated by upgrading to a newer version of those. On
          linux, you can also load the microcode from the kernel if you are
          using an AMD family 10h or later processor (first introduced late
          2007), or an Intel processor from 1998 and later (Pentium4, Core,
          etc), if updated microcode has been released. These updates only
          last until the machine is powered off, so they need to be applied
          on every boot.
        </p>
        <p>
          Intel provide updates of their microcode for SandyBridge and later
          processors as new vulnerabilities come to light. New versions of
          AMD firmware are rare and usually only apply to a few models,
          although motherboard manufacturers get extra updates which maybe
          update microcode along with the changes to support newer CPUs and
          faster memory.
        </p>
        <p>
          There are two ways of loading the microcode, described as 'early'
          and 'late'. Early loading happens before userspace has been
          started, late loading happens after userspace has started. Not
          surprisingly, early loading is preferred, (see e.g. an explanatory
          comment in a kernel commit noted at <a class="ulink" href=
          "https://lwn.net/Articles/530346/">x86/microcode: Early load
          microcode</a> on LWN.) Indeed, it is needed to work around one
          particular erratum in early Intel Haswell processors which had TSX
          enabled. (See <a class="ulink" href=
          "http://www.anandtech.com/show/8376/intel-disables-tsx-instructions-erratum-found-in-haswell-haswelleep-broadwellyi/">
          Intel Disables TSX Instructions: Erratum Found in Haswell,
          Haswell-E/EP, Broadwell-Y</a>.) Without this update glibc can do
          the wrong thing in uncommon situations.
        </p>
        <p>
          It is still possible to manually force late loading of microcode,
          either for testing or to prevent having to reboot. You will need to
          reconfigure your kernel for either method. The instructions here
          will create a kernel <code class="filename">.config</code> to suite
          early loading, before forcing late loading to see if there is any
          microcode. If there is, the instructions then show you how to
          create an initrd for early loading.
        </p>
        <p>
          To confirm what processor(s) you have (if more than one, they will
          be identical) look in /proc/cpuinfo.
        </p>
        <div class="sect3" lang="en" xml:lang="en">
          <h3 class="sect3">
            <a id="intel-microcode" name="intel-microcode"></a>
          </h3>
          <h4 class="title">
            <a id="intel-microcode" name="intel-microcode"></a>Intel
            Microcode for the CPU
          </h4>
          <p>
            The first step is to get the most recent version of the Intel
            microcode. This must be done by navigating to <a class="ulink"
            href=
            "https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/">
            https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/</a>
            and downloading the latest file there. As of this writing the
            most recent version of the microcode is microcode-20191115.
            Extract this file in the normal way, the microcode is in the
            <code class="filename">intel-ucode</code> directory, containing
            various blobs with names in the form XX-YY-ZZ. There are also
            various other files, and a releasenote.
          </p>
          <p>
            In the past, intel did not provide any details of which blobs had
            changed versions, but now the release note details this.
          </p>
          <p>
            The recent firmware for older processors is provided to deal with
            vulnerabilities which have now been made public, and for some of
            these such as Microarchitectural Data Sampling (MDS) you might
            wish to increase the protection by disabling hyperthreading, or
            alternatively to disable the kernel's default mitigation because
            of its impact on compile times. Please read the online
            documentation at <a class="ulink" href=
            "https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/index.html">
            https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/index.html</a>.
          </p>
          <p>
            To be able to use this latest microcode to provide mitigation on
            all the affected processors, the kernel version needs to be at
            least 5.3.11 (or 4.19.84 if you are using the 4.19 long term
            support series).
          </p>
          <p>
            Now you need to determine your processor's identity to see if
            there is any microcode for it. Determine the decimal values of
            the cpu family, model and stepping by running the following
            command (it will also report the current microcode version):
          </p>
          <pre class="userinput">
<kbd class="command">head -n7 /proc/cpuinfo</kbd>
</pre>
          <p>
            Convert the cpu family, model and stepping to pairs of
            hexadecimal digits. For a Skylake i3 6100 (described as Intel(R)
            Core(TM) i3-6100 CPU) the relevant values are cpu family 6, model
            94, stepping 3 so in this case the required identification is
            06-5e-03. A look at the blobs will show that there is one for
            this CPU (although for older issues it might have already been
            applied by the BIOS). If there is a blob for your system then
            test if it will be applied by copying it (replace
            &lt;XX-YY-ZZ&gt; by the identifier for your machine) to where the
            kernel can find it:
          </p>
          <pre class="userinput">
<kbd class="command">mkdir -pv /lib/firmware/intel-ucode
cp -v intel-ucode/&lt;XX-YY-ZZ&gt; /lib/firmware/intel-ucode</kbd>
</pre>
          <p>
            Now that the Intel microcode has been prepared, use the following
            options when you configure the kernel to load Intel microcode:
          </p>
          <pre class="screen">
<code class="literal">General Setup ---&gt;
  [y] Initial RAM filesystem and RAM disk (initramfs/initrd) support [CONFIG_BLK_DEV_INITRD]
Processor type and features  ---&gt;
  [y] CPU microcode loading support  [CONFIG_MICROCODE]
  [y]      Intel microcode loading support [CONFIG_MICROCODE_INTEL]</code>
</pre>
          <p>
            After you have successfully booted the new system, force late
            loading by using the command:
          </p>
          <pre class="userinput">
<kbd class=
"command">echo 1 &gt; /sys/devices/system/cpu/microcode/reload</kbd>
</pre>
          <p>
            Then use the following command to see if anything was loaded:
          </p>
          <pre class="userinput">
<kbd class=
"command">dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'</kbd>
</pre>
          <p>
            This reformatted example was created by temporarily booting
            without microcode, to show the current Firmware Bug message, then
            the late load shows it being updated to revision 0xd6.
          </p>
          <pre class="screen">
<code class=
"literal">[    0.000000] Linux version 5.4.2 (lfs@leshp) (gcc version 9.2.0 (GCC))
               #1 SMP PREEMPT Wed Dec 18 11:52:13 GMT 2019
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-5.4.2-sda11 root=/dev/sda11 ro
[    0.020218] [Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode
               to version: 0xb2 (or later)
[    0.153861] MDS: Vulnerable: Clear CPU buffers attempted, no microcode
[    0.550009] microcode: sig=0x506e3, pf=0x2, revision=0x74
[    0.550036] microcode: Microcode Update Driver: v2.2.
[  277.673064] microcode: updated to revision 0xd6, date = 2019-10-03
[  277.674231] x86/CPU: CPU features have changed after loading microcode, but might not take effect</code>
</pre>
          <p>
            If the microcode was not updated, there is no new microcode for
            this system's processor. If it did get updated, you can now
            proceed to <a class="xref" href="firmware.html#early-microcode"
            title="Early loading of microcode">the section called
            &ldquo;Early loading of microcode&rdquo;</a>.
          </p>
        </div>
        <div class="sect3" lang="en" xml:lang="en">
          <h3 class="sect3">
            <a id="and-microcode" name="and-microcode"></a>
          </h3>
          <h4 class="title">
            <a id="and-microcode" name="and-microcode"></a>AMD Microcode for
            the CPU
          </h4>
          <p>
            Begin by downloading a container of firmware for your CPU family
            from <a class="ulink" href=
            "http://anduin.linuxfromscratch.org/BLFS/linux-firmware/amd-ucode/">
            http://anduin.linuxfromscratch.org/BLFS/linux-firmware/amd-ucode/</a>.
            The family is always specified in hex. Families 10h to 14h (16 to
            20) are in microcode_amd.bin. Families 15h, 16h and 17h have
            their own containers. Create the required directory and put the
            firmware you downloaded into it as the <code class=
            "systemitem">root</code> user:
          </p>
          <pre class="userinput">
<kbd class="command">mkdir -pv /lib/firmware/amd-ucode
cp -v microcode_amd* /lib/firmware/amd-ucode</kbd>
</pre>
          <p>
            When you configure the kernel, use the following options to load
            AMD microcode:
          </p>
          <pre class="screen">
<code class="literal">General Setup ---&gt;
  [y] Initial RAM filesystem and RAM disk (initramfs/initrd) support [CONFIG_BLK_DEV_INITRD]
Processor type and features  ---&gt;
  [y] CPU microcode loading support  [CONFIG_MICROCODE]
  [y]      AMD microcode loading support [CONFIG_MICROCODE_AMD]</code>
</pre>
          <p>
            After you have successfully booted the new system, force late
            loading by using the command:
          </p>
          <pre class="userinput">
<kbd class=
"command">echo 1 &gt; /sys/devices/system/cpu/microcode/reload</kbd>
</pre>
          <p>
            Then use the following command to see if anything was loaded:
          </p>
          <pre class="userinput">
<kbd class=
"command">dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'</kbd>
</pre>
          <p>
            This historic example from an old Athlon(tm) II X2 shows it has
            been updated. At that time, all CPUs were still reported in the
            microcode details on AMD machines (the current position for AMD
            machines where newer microcode is available is unknown) :
          </p>
          <pre class="screen">
<code class=
"literal">[    0.000000] Linux version 4.15.3 (ken@testserver) (gcc version 7.3.0 (GCC))
               #1 SMP Sun Feb 18 02:08:12 GMT 2018
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.15.3-sda5 root=/dev/sda5 ro
[    0.307619] microcode: CPU0: patch_level=0x010000b6
[    0.307671] microcode: CPU1: patch_level=0x010000b6
[    0.307743] microcode: Microcode Update Driver: v2.2.
[  187.928891] microcode: CPU0: new patch_level=0x010000c8
[  187.928899] microcode: CPU1: new patch_level=0x010000c8</code>
</pre>
          <p>
            If the microcode was not updated, there is no new microcode for
            this system's processor. If it did get updated, you can now
            proceed to <a class="xref" href="firmware.html#early-microcode"
            title="Early loading of microcode">the section called
            &ldquo;Early loading of microcode&rdquo;</a>.
          </p>
        </div>
        <div class="sect3" lang="en" xml:lang="en">
          <h3 class="sect3">
            <a id="early-microcode" name="early-microcode"></a>
          </h3>
          <h4 class="title">
            <a id="early-microcode" name="early-microcode"></a>Early loading
            of microcode
          </h4>
          <p>
            If you have established that updated microcode is available for
            your system, it is time to prepare it for early loading. This
            requires an additional package, <a class="xref" href=
            "../general/cpio.html" title="cpio-2.13">cpio-2.13</a> and the
            creation of an initrd which will need to be added to grub.cfg.
          </p>
          <p>
            It does not matter where you prepare the initrd, and once it is
            working you can apply the same initrd to later LFS systems or
            newer kernels on this same machine, at least until any newer
            microcode is released. Use the following commands:
          </p>
          <pre class="userinput">
<kbd class="command">mkdir -p initrd/kernel/x86/microcode
cd initrd</kbd>
</pre>
          <p>
            For an AMD machine, use the following command (replace
            &lt;MYCONTAINER&gt; with the name of the container for your CPU's
            family):
          </p>
          <pre class="userinput">
<kbd class=
"command">cp -v /lib/firmware/amd-ucode/&lt;MYCONTAINER&gt; kernel/x86/microcode/AuthenticAMD.bin</kbd>
</pre>
          <p>
            Or for an Intel machine copy the appropriate blob using this
            command:
          </p>
          <pre class="userinput">
<kbd class=
"command">cp -v /lib/firmware/intel-ucode/&lt;XX-YY-ZZ&gt; kernel/x86/microcode/GenuineIntel.bin</kbd>
</pre>
          <p>
            Now prepare the initrd:
          </p>
          <pre class="userinput">
<kbd class="command">find . | cpio -o -H newc &gt; /boot/microcode.img</kbd>
</pre>
          <p>
            You now need to add a new entry to /boot/grub/grub.cfg and here
            you should add a new line after the linux line within the stanza.
            If /boot is a separate mountpoint:
          </p>
          <pre class="userinput">
<kbd class="command">initrd /microcode.img</kbd>
</pre>
          <p>
            or this if it is not:
          </p>
          <pre class="userinput">
<kbd class="command">initrd /boot/microcode.img</kbd>
</pre>
          <p>
            If you are already booting with an initrd (see <a class="xref"
            href="initramfs.html" title="About initramfs">the section called
            &ldquo;About initramfs&rdquo;</a>), you should run <span class=
            "command"><strong>mkinitramfs</strong></span> again after putting
            the appropriate blob or container into <code class=
            "filename">/lib/firmware</code> as explained above.
            Alternatively, you can have both initrd on the same line, such as
            <strong class="userinput"><code>initrd /microcode.img
            /other-initrd.img</code></strong> (adapt that as above if /boot
            is not a separate mountpoint).
          </p>
          <p>
            You can now reboot with the added initrd, and then use the same
            command to check that the early load worked.
          </p>
          <pre class="userinput">
<kbd class=
"command">dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'</kbd>
</pre>
          <p>
            If you updated to address vulnerabilities, you can look at
            <code class=
            "filename">/sys/devices/system/cpu/vulnerabilities/</code> to see
            what is now reported.
          </p>
          <p>
            The places and times where early loading happens are very
            different in AMD and Intel machines. First, an Intel example with
            early loading:
          </p>
          <pre class="screen">
<code class=
"literal">[    0.000000] microcode: microcode updated early to revision 0xd6, date = 2019-10-03
[    0.000000] Linux version 5.4.6 (ken@leshp) (gcc version 9.2.0 (GCC))i
               #4 SMP PREEMPT Sat Dec 21 21:41:03 GMT 2019
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-5.4.6-sda11 root=/dev/sda11 ro resume=/dev/sda10
[    0.579936] microcode: sig=0x506e3, pf=0x2, revision=0xd6
[    0.579961] microcode: Microcode Update Driver: v2.2.</code>
</pre>
          <p>
            A historic AMD example:
          </p>
          <pre class="screen">
<code class=
"literal">[    0.000000] Linux version 4.15.3 (ken@testserver) (gcc version 7.3.0 (GCC))
               #2 SMP Sun Feb 18 02:32:03 GMT 2018
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.15.3-sda5 root=/dev/sda5 ro
[    0.307619] microcode: microcode updated early to new patch_level=0x010000c8
[    0.307678] microcode: CPU0: patch_level=0x010000c8
[    0.307723] microcode: CPU1: patch_level=0x010000c8
[    0.307795] microcode: Microcode Update Driver: v2.2.</code>
</pre>
        </div>
      </div>
      <div class="sect2" lang="en" xml:lang="en">
        <h2 class="sect2">
          <a id="video-firmware" name="video-firmware"></a>Firmware for Video
          Cards
        </h2>
        <div class="sect3" lang="en" xml:lang="en">
          <h3 class="sect3">
            <a id="ati-video-firmware" name="ati-video-firmware"></a>
          </h3>
          <h4 class="title">
            <a id="ati-video-firmware" name="ati-video-firmware"></a>Firmware
            for ATI video chips (R600 and later)
          </h4>
          <p>
            These instructions do NOT apply to old radeons before the R600
            family. For those, the firmware is in the kernel's <code class=
            "filename">/lib/firmware/</code> directory. Nor do they apply if
            you intend to avoid a graphical setup such as Xorg and are
            content to use the default 80x25 display rather than a
            framebuffer.
          </p>
          <p>
            Early radeon devices only needed a single 2K blob of firmware.
            Recent devices need several different blobs, and some of them are
            much bigger. The total size of the radeon firmware directory is
            over 500K &mdash; on a large modern system you can probably spare
            the space, but it is still redundant to install all the unused
            files each time you build a system.
          </p>
          <p>
            A better approach is to install <a class="xref" href=
            "../general/pciutils.html" title=
            "pciutils-3.6.4">pciutils-3.6.4</a> and then use <strong class=
            "userinput"><code>lspci</code></strong> to identify which VGA
            controller is installed.
          </p>
          <p>
            With that information, check the RadeonFeature page of the Xorg
            wiki for <a class="ulink" href=
            "http://wiki.x.org/wiki/RadeonFeature/#index5h2">Decoder ring for
            engineering vs marketing names</a> to identify the family (you
            may need to know this for the Xorg driver in BLFS &mdash;
            Southern Islands and Sea Islands use the radeonsi driver) and the
            specific model.
          </p>
          <p>
            Now that you know which controller you are using, consult the
            <a class="ulink" href=
            "https://wiki.gentoo.org/wiki/Radeon#Firmware">Radeon</a> page of
            the Gentoo wiki which has a table listing the required firmware
            blobs for the various chipsets. Note that Southern Islands and
            Sea Islands chips use different firmware for kernel 3.17 and
            later compared to earlier kernels. Identify and download the
            required blobs then install them:
          </p>
          <pre class="userinput">
<kbd class="command">mkdir -pv /lib/firmware/radeon
cp -v &lt;YOUR_BLOBS&gt; /lib/firmware/radeon</kbd>
</pre>
          <p>
            There are actually two ways of installing this firmware. BLFS, in
            the 'Kernel Configuration for additional firmware' section part
            of the <a class="xref" href="../x/x7driver.html#xorg-ati-driver"
            title="Xorg ATI Driver-19.1.0">Xorg ATI Driver-19.1.0</a> section
            gives an example of compiling the firmware into the kernel - that
            is slightly faster to load, but uses more kernel memory. Here we
            will use the alternative method of making the radeon driver a
            module. In your kernel config set the following:
          </p>
          <pre class="screen">
<code class="literal">Device Drivers ---&gt;
  Graphics support ---&gt;
      Direct Rendering Manager ---&gt;
        &lt;*&gt; Direct Rendering Manager (XFree86 ... support)  [CONFIG_DRM]
      &lt;m&gt; ATI Radeon                                        [CONFIG_DRM_RADEON]</code>
</pre>
          <p>
            Loading several large blobs from /lib/firmware takes a noticeable
            time, during which the screen will be blank. If you do not enable
            the penguin framebuffer logo, or change the console size by using
            a bigger font, that probably does not matter. If desired, you can
            slightly reduce the time if you follow the alternate method of
            specifying 'y' for CONFIG_DRM_RADEON covered in BLFS at the link
            above &mdash; you must specify each needed radeon blob if you do
            that.
          </p>
        </div>
        <div class="sect3" lang="en" xml:lang="en">
          <h3 class="sect3">
            <a id="nvidia-video-firmware" name="nvidia-video-firmware"></a>
          </h3>
          <h4 class="title">
            <a id="nvidia-video-firmware" name=
            "nvidia-video-firmware"></a>Firmware for Nvidia video chips
          </h4>
          <p>
            Some Nvidia graphics chips need firmware updates to take
            advantage of all the card's capability. These are generally the
            GeForce 8, 9, 9300, and 200-900 series chips. For more exact
            information, see <a class="ulink" href=
            "https://nouveau.freedesktop.org/wiki/VideoAcceleration/#firmware">
            https://nouveau.freedesktop.org/wiki/VideoAcceleration/#firmware</a>.
          </p>
          <p>
            First, the kernel Nvidia driver must be activated:
          </p>
          <pre class="screen">
<code class="literal">Device Drivers ---&gt;
  Graphics support ---&gt;
      Direct Rendering Manager ---&gt;
        &lt;*&gt; Direct Rendering Manager (XFree86 ... support)  [CONFIG_DRM]
      &lt;*/m&gt; Nouveau (NVIDIA) cards                          [CONFIG_DRM_NOUVEAU]</code>
</pre>
          <p>
            The steps to install the Nvidia firmware are:
          </p>
          <pre class="userinput">
<kbd class=
"command">wget https://raw.github.com/imirkin/re-vp2/master/extract_firmware.py
wget http://us.download.nvidia.com/XFree86/Linux-x86/325.15/NVIDIA-Linux-x86-325.15.run
sh NVIDIA-Linux-x86-325.15.run --extract-only
python extract_firmware.py 
mkdir -p /lib/firmware/nouveau
cp -d nv* vuc-* /lib/firmware/nouveau/</kbd>
</pre>
        </div>
      </div>
      <div class="sect2" lang="en" xml:lang="en">
        <h2 class="sect2">
          <a id="nic-firmware" name="nic-firmware"></a>Firmware for Network
          Interfaces
        </h2>
        <p>
          The kernel likes to load firmware for some network drivers,
          particularly those from Realtek (the /lib/linux-firmware/rtl_nic/)
          directory, but they generally appear to work without it. Therefore,
          you can boot the kernel, check dmesg for messages about this
          missing firmware, and if necessary download the firmware and put it
          in the specified directory in /lib/firmware so that it will be
          found on subsequent boots. Note that with current kernels this
          works whether or not the driver is compiled in or built as a
          module, there is no need to build this firmware into the kernel.
          Here is an example where the R8169 driver has been compiled in but
          the firmware was not made available. Once the firmware had been
          provided, there was no mention of it on later boots.
        </p>
        <pre class="screen">
<code class="literal">dmesg | grep firmware | grep r8169
[    7.018028] r8169 0000:01:00.0: Direct firmware load for rtl_nic/rtl8168g-2.fw failed with error -2
[    7.018036] r8169 0000:01:00.0 eth0: unable to load firmware patch rtl_nic/rtl8168g-2.fw (-2)</code>
</pre>
      </div>
      <div class="sect2" lang="en" xml:lang="en">
        <h2 class="sect2">
          <a id="other-firmware" name="other-firmware"></a>Firmware for Other
          Devices
        </h2>
        <p>
          Identifying the correct firmware will typically require you to
          install <a class="xref" href="../general/pciutils.html" title=
          "pciutils-3.6.4">pciutils-3.6.4</a>, and then use <strong class=
          "userinput"><code>lspci</code></strong> to identify the device. You
          should then search online to check which module it uses, which
          firmware, and where to obtain the firmware &mdash; not all of it is
          in linux-firmware.
        </p>
        <p>
          If possible, you should begin by using a wired connection when you
          first boot your LFS system. To use a wireless connection you will
          need to use a network tools such as <a class="xref" href=
          "../basicnet/wireless_tools.html" title=
          "Wireless Tools-29">Wireless Tools-29</a> and <a class="xref" href=
          "../basicnet/wpa_supplicant.html" title=
          "wpa_supplicant-2.9">wpa_supplicant-2.9</a>.
        </p>
        <p>
          Firmware may also be needed for other devices such as some SCSI
          controllers, bluetooth adaptors, or TV recorders. The same
          principles apply.
        </p>
      </div>
      <p class="updated">
        Last updated on 2020-01-09 08:18:14 -0800
      </p>
    </div>
    <div class="navfooter">
      <ul>
        <li class="prev">
          <a accesskey="p" href="console-fonts.html" title=
          "About Console Fonts">Prev</a>
          <p>
            About Console Fonts
          </p>
        </li>
        <li class="next">
          <a accesskey="n" href="devices.html" title="About Devices">Next</a>
          <p>
            About Devices
          </p>
        </li>
        <li class="up">
          <a accesskey="u" href="config.html" title=
          "Chapter&nbsp;3.&nbsp;After LFS Configuration Issues">Up</a>
        </li>
        <li class="home">
          <a accesskey="h" href="../index.html" title=
          "Beyond Linux� From Scratch     (System V Edition) - Version 9.1">Home</a>
        </li>
      </ul>
    </div>
  </body>
</html>
